Information transactions over a network

ABSTRACT

In one example, a method for managing information in an environment that includes a client device includes accessing, at the client device, an electronic input interface. Next, the client device transmits a signal to a host system associated with the electronic input interface by entering consumer profile information into the electronic input interface. A request is then made for creation of an information account for storage of the consumer profile information. The client device then receives authentication information from the host system. Finally, the client device enables the vendor to access some of the consumer profile information stored in the information account.

RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 09/988,811, filed Nov. 20, 2001, which is acontinuation-in-part of U.S. patent application Ser. No. 09/974,766(U.S. Pat. No. 7,016,875), filed Oct. 9, 2001, which is acontinuation-in-part of U.S. patent application Ser. No. 09/933,567,(U.S. Pat. No. 7,467,141), filed Aug. 20, 2001, which is acontinuation-in-part of U.S. patent application Ser. No. 09/923,285,(U.S. Pat. No. 7,257,581), filed Aug. 6, 2001 (which claims the benefitof U.S. Provisional Patent Application Ser. Nos. 60/223,232 filed Aug.4, 2000, 60/226,117 filed Aug. 18, 2000, 60/238,847 filed Oct. 6, 2000,60/245,867 filed Nov. 7, 2000, and 60/253,298 filed Nov. 27, 2000). Allof the aforementioned applications are incorporated herein in theirentirety by this reference.

BACKGROUND OF THE INVENTION

As information technology and network technology become more prolific,people find themselves repeatedly and manually inputting the same datainto different computer systems. For example, consumers may findthemselves having to manually input their personal and billinginformation via each vendor website through which they choose tocomplete an electronic commerce (“e-commerce”) or mobile commerce(“m-commerce”) transaction. As the number of secure websites grows,consumers also find themselves having to manage numerous usernames andpasswords. Thus, there is a need for a convenient and secure system forautomating the management of consumer information.

Automated or partially automated solutions for managing informationhistorically have largely been localized processes. Using conventionaltechniques, users are able to create and store data files containingpersonal information on their personal computers or other clientdevices, such as personal digital assistants (“PDAs”), pagers, mobiletelephones, etc. The data elements in such data files can be sharedusing specialized applications for filtering data out of the data fileand into another application. However, such systems typically require apermanent download of proprietary data management software that mightnot be compatible among different devices. In addition, the datamanagement software and data files are often stored on only a singlepersonal computer or computerized device. If the personal computer orother computerized device becomes lost or stolen, the user's data may nolonger be accessible, and might end up in the possession of anotherperson. If the personal computer or other computerized device crashes,the data can easily be lost.

From the perspective of providers, such as vendors of on-line productsor services, it can be valuable to have access to consumer informationin order to, for example, facilitate e-commerce or m-commercetransactions, or else to better understand consumers or communicate withthem about products or services in which they might be interested.However, consumers are often reluctant to provide their personalinformation, often in part due to concerns over security of theinformation. Also, consumers may not want to take the time to re-entertheir personal information at different on-line provider sites.Providers of on-line products or services may therefore benefit from amechanism which entices consumers to provide their personal informationby minimizing the burden on consumers when conducting on-linetransactions requiring personal information and by allowing consumers toretain control over the type and amount of information that is releasedto the provider.

Accordingly, there remains a need for a more secure, flexible andconvenient system for storing information and a method for allowing theuser to manage and distribute that information using a personal computeror other network-connected device. There further remains a need for sucha system and method that provides central information storage and doesnot require a permanent download of proprietary software to a clientdevice for management and distribution of the information. Additionally,there is a need for a mechanism which encourages consumers to providetheir personal information to provider of on-line products or services.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level block diagram illustrating a system in accordancewith one or more exemplary embodiments as disclosed herein.

FIG. 2 is an abstract illustration of an information account inaccordance with exemplary embodiments as may be used, for example, inthe system illustrated in FIG. 1.

FIG. 3 is an abstract illustration of another information account inaccordance with other exemplary embodiments as may be used, for example,in the system illustrated in FIG. 1.

FIG. 4 is an abstract illustration of an exemplary database schema inaccordance with certain exemplary embodiments.

FIG. 5 is a generalized interaction diagram illustrating the interactionbetween various system components of certain exemplary embodiments asdisclosed herein.

FIG. 6 is a generalized interaction diagram illustrating the interactionbetween various system components when a new information account iscreated by a consumer via a vendor's website, in accordance with one ormore exemplary embodiments.

FIG. 7 is a generalized interaction diagram illustrating the interactionbetween various system components in an exemplary wireless environment.

FIG. 8 is a high-level block diagram illustrating logical grouping ofvendor servers into exchanges in accordance with one or more exemplaryembodiments as disclosed herein.

FIG. 9 is an illustration of a web page displaying logos that identify abranded information account and exchange membership in accordance withone or more exemplary embodiments as disclosed herein.

FIG. 10 is an abstract illustration of exemplary system components forimplementing revenue sharing models in accordance with certain exemplaryembodiments.

DETAILED DESCRIPTION OF SOME EXAMPLE EMBODIMENTS

In one or more embodiments, a system and method are provided forenabling consumers to store and maintain a comprehensive informationprofile (hereinafter “information account”) in a centralized datarepository that is accessible over a distributed electronic network,such as the Internet. The information account may be used to store anytype of data desired by the consumer, including, for example,demographic information, financial information, medical information,family information, contact information, documents, image files,multimedia files, etc. The centralized data repository is preferablyaccessible via a network by any authorized network device. In variousembodiments, no specialized application programs are required to bepermanently downloaded to the consumer's network device in order toaccess the information account.

According to certain embodiments, at the consumer's direction, selectedinformation in the information account may be accessed and, if desired,shared with authorized vendors, business partners or any other entitythat requires certain of the consumer's information. The terms “vendor”and “business partner” are used herein in a general sense to refer topersons, businesses, enterprises or entities that make products orservices available to consumers. As used herein, the terms “consumer,”“buyer,” and “user” are interchangeable.

Server-side software or temporary client-side software may, in someembodiments, be used to manage communications with the informationaccount and to automatically integrate that consumer information into aprocess executed by a network device. As an example, the network devicemay execute a business process relating to a consumer-initiatedactivity, such as a retail transaction. The server-side software ortemporary client-side software may receive consumer information from theinformation account and use that information to automatically populatethe input fields of a form or the input requirements of a process thatis to be submitted to a vendor's server or other network device duringan application, registration or transaction process.

The data in the information account is preferably stored using a taggeddata format. In one embodiment, the data in the information account maybe stored using the eXtensible Markup Language (“XML”) data format,which is an open standard for describing data from the World Wide WebConsortium (“W3C”). As is known in the art, XML tags are used to definethe types of information that are represented by the data element. TheXML standard provides a great deal of flexibility in that custom tagsmay be defined for any type of information that the consumer may desireto store in the information account. Using any well-known XML-relatedquerying, parsing, transforming and/or filtering techniques, individualdata elements in the information account may be accessed, updated,deleted, created, or otherwise manipulated.

The information account may be structured as one or more dataaggregates, e.g., XML data aggregates. An entire XML data aggregate isstored within a data field of a database table. This data field is along text field containing all of the information associated with thegiven record. In one embodiment, all consumer information in theinformation account may be stored in a single XML data aggregatecomprising consumer information elements and sub-elements. Attributesmay also be associated with any element and sub-element in order toprovide additional information. A transformation or filtering mechanism,such as “Style Sheets,” may be applied to the single XML data stream inorder to extract only selected data elements therefrom at the directionof the consumer.

In an alternative embodiment, the information account may be normalizedinto a plurality of discrete data aggregates, each aggregaterepresenting a predetermined “information product.” An informationproduct refers to a package of consumer information relating to aspecific product or service offered by a vendor. For example, a mortgageinformation product might contain all consumer information that would berequired to complete a lender's mortgage application. Individualinformation products may be retrieved from the information account andtransmitted to authorized vendors at the request of the consumer.

Access constraints may be utilized in one or more embodiments asdescribed herein to allow for the establishment of “exchanges.” Anexchange generally refers to a group of entities that are authorized toaccept consumer information from the information account at the requestof the consumer. The information account may be accessed for retrievalof information to be used in commerce with any vendor or entity that isa member of the exchange. In much the same way that a consumer may haveseveral different credit cards or debit cards that are each acceptedonly by certain merchants, the consumer may have several informationaccounts that are each valid only on specified exchanges.

Exchanges may be implemented, for example, through “inflow” and/or“outflow” constraints imposed by the exchanges. An inflow constraintimposed by an exchange may, for example, dictate that only informationaccounts associated with specific other exchanges will be accepted orthat no information accounts associated with other exchanges will beaccepted. An outflow constraint may dictate that information accountsassociated with an exchange may only be used within that exchange andwithin no other exchanges. Various business situations and partnershipsmay drive the implementation of inflow and outflow constraints. Revenuesharing models may be established in order to provide financialincentives to exchanges and/or individual vendors that facilitate thecreation of an information account or the use of an information accountto complete a transaction.

Exemplary embodiments will now be described with reference to thedrawings, in which like numerals represent like elements throughout theseveral figures. A high-level block diagram of a system in accordancewith an exemplary embodiment is shown in and described with reference toFIG. 1. As shown, a central data repository 102 is provided for storingconsumer information that may be easily accessed from any network deviceattached to the network 106. The network 106 may comprise anytelecommunication and/or data network, whether public or private, suchas a local area network, a wide area network, an intranet, an internetand any combination thereof and may be wireline and/or wireless. Variousmethodologies as described herein may be practiced in the context ofdistributed computing environments. The network 106 thus provides forthe open and seamless distribution of consumer information to and fromthe information account 110.

In the system illustrated in FIG. 1, the exemplary operating environmentencompasses various network devices for accessing and reading associatedcomputer-readable media having stored thereon data and/orcomputer-executable instructions for implementing various methods of thepresent invention of data storage, management and distribution.Generally, a network device includes a communication device fortransmitting and receiving data and/or computer-executable instructionsover the network 106, and a memory for storing data and/orcomputer-executable instructions. A network device may also include aprocessor for processing data and executing computer-executableinstructions, as well as other internal and peripheral components thatare well known in the art (e.g., input and output devices.) As usedherein, the term “computer-readable medium” describes any form ofcomputer memory or a propagated signal transmission medium. Propagatedsignals representing data and computer-executable instructions aretransferred between network devices.

A network device may generally comprise any device that is capable ofcommunicating with the resources of the network 106. A network devicemay comprise, for example, a network server 108 & 114, a client device104, a wireless client device 104 a or a dedicated storage device (e.g.,the central data repository 102.) In the embodiment shown in FIG. 1, ahost server 108 hosts the software for interacting with the central datarepository 102 and for communicating with other network devices. Thehost server 108 may interact with the central data repository 102 viathe network 106 or via a direct communication link 111. A vendor server114 hosts vendor web page files 116 comprising a vendor website, throughwhich products or services may be offered to consumers.

A client device 104 may comprise a desktop computer, a laptop computerand the like. A wireless client device 104 a may comprise a personaldigital assistant (PDA), a digital and/or cellular telephone or pager, ahandheld computer, or any other mobile device. These and other types ofclient devices 104 & 104 a will be apparent to one of ordinary skill inthe art. For convenience, the following explanation will be made withreference to a client device 104 generically, but, unless otherwiseindicated, it will be understood that the principles and conceptsdescribed will also encompass wired or wireless devices, such aswireless client device 104 a illustrated in FIG. 1. Moreover, althoughexemplary embodiments will be described herein in the context of theInternet or a web-based environment, it will be appreciated that thevarious principles and methods of operation will be applicable or may bepracticed in other environments as well.

According to a preferred embodiment, a client device 104 may execute abrowser 112 or another suitable application for interacting with webpage files 116 hosted by a vendor server 114 and other network devices.Through the graphical user interface provided by a displayed web pagefile 116, the vendor may require the consumer (i.e., the operator of theclient device 104) to input certain information pertaining to orassociated with the consumer. According to certain embodiments, aconsumer may be permitted to direct that the requested information betransmitted from the information account 110 to the client device 104for processing. Although exemplary embodiments will be described hereinin the context of a web-based environment, those skilled in the art willappreciate that other environments are suitable as well.

The description of exemplary embodiments with reference to FIG. 1assumes the existence of a previously created information account 110.An example illustrating actual creation of an information account 110will be described below with reference to FIG. 6. In general, theinformation account 110 may be any data structure for storing consumerinformation. Preferably, however, the information account 110 is storedas a tagged data structure, such as one or more XML data aggregates. Thedata in the information account 110 is preferably encrypted so thatanyone gaining unauthorized access to the information account 110 willnot be able to read the data. Also, in a preferred embodiment, eachinformation account 110 in the central data repository 102 is encryptedseparately, so that someone authorized to access the information accountof one consumer may not also gain access to the information account ofanother consumer.

In accordance with a preferred embodiment, the consumers may maintainsole responsibility for storing and updating the information in theinformation account 110. Only the consumer, or those authorized by theconsumer, may use the information account 110 to complete e-commerce orm-commerce activities. Consumers create an information account 110either through a website hosted by the host server 108 or a websitehosted by a vendor server 114. For example, after manually completing aform displayed by a vendor's website, the consumer can choose to createan information account 110 and have the consumer information storedtherein.

Upon creation of an information account 110, a consumer may be given anidentification number, a username and/or a password. Other types ofconsumer authentication information are known in the art and may also beused in the context of the present invention. The system of FIG. 1provides the consumer with a variety of methods of accessing theinformation account 110, transferring selected information to a vendorand/or allowing a vendor limited and constrained access to theinformation account 110, as described in further detail herein.

In one embodiment as described herein, a single sign-on mechanism may beprovided to allow a consumer to “sign-on” (provide username andpassword, etc.) for authentication to access an information account 110at only a first website. The authentication status may then “follow” theconsumer as the consumer accesses subsequent websites. At suchsubsequent websites, a consumer who has activated the single sign-onmechanism will not be asked to re-authenticate himself. For example, thehost server 108 may maintain an authentication table (not shown) thatrecords the consumer authenticatic information, the sign-on time and abrowser identifier. When the consumer accesses a subsequent website thatrequires sign-on for accessing the information account 110, theclient-side application 105 may communicate the browser identifier tothe host server 108. The host server 108 may use the browser identifierto look up the consumer authentication information and previous sign-ontime in the authentication table. The previous sign-on time may becompared to the current time in order to determine whether a time-outinterval has expired. If the time-out interval has not expired, the hostserver 108 may acknowledge that the consumer is authenticated.

A web page file 116 displayed by the browser 112 may include inputfields for the input of consumer information. The web page file 116 mayalso include an instruction (e.g., a “call”) that causes the browser 112to download and execute a client-side application 105. JAVA applets arewell known client-side applications and are particularly suited for usein various embodiments due to their platform-independent nature.However, any other type of client-side application may be used withoutdeparting from the spirit and scope of the present invention. Theclient-side application 105 resides in temporary memory storage of theclient device 104, such as cache memory or the like, and may be removedfrom the client device 104 after its execution is complete. Theclient-side application 105 is specific to the browser session only andnot to the client device 104. Multiple client-side applications 105 maybe executed at the same time if multiple browser windows are executed bythe client device 104. The client-side application 105 providesfunctionality for facilitating communications between the browser 112executed by the client device 104 and the database management system(“DBMS”) 109 of the host server 108.

One responsibility of the client-side application 105 is to provideauthentication information associated with the consumer and the vendorto the host server 108. Depending on the desired level of securitywithin the system, authentication information may comprise a username,user ID, password, key, certificate and the like. Authenticationinformation regarding the vendor may be embedded within the web pagefile 116 for extraction by the client-side application 105.Alternatively, the client-side application 105 may communicate with thevendor server 114 to retrieve such vendor authentication information.Authentication information regarding the consumer may be supplied by theconsumer via a user interface displayed by the client-side application105. Communications relating to authentication information may beaccomplished using a secure transmission protocol or handshake, such asthe secure shell BSD, Point to Point Tunneling Protocol (PPTP), alsocommonly know as Virtual Private Network, and/or secure socket layering(SSL) protocol. Other methods for achieving a secure connection over thenetwork 106 will be apparent to those of ordinary skill in the art.Authentication information may also be encrypted and transmitted over anopen network using any appropriate protocol.

The client-side application 105 is also responsible for determining thetype of consumer information that is required by the input fields of thedisplayed web page file 116. After determining the type of consumerinformation that is required, the client-side application 105 mayformulate a database query in a language that is understood by the DBMS109. At a minimum, client-side application 105 communicates enoughinformation to the DBMS 109 regarding the required consumer informationso that the DBMS can formulate a database query. In one embodiment, theDBMS 109 exposes an application program interface (“API”) that can beutilized by the client-side application 105. An example of one such APIis known as the Simple Object Access Protocol (“SOAP”). SOAP is aprotocol that provides for interoperability between heterogeneousHTTP-based software and XML-based software. SOAP provides access toservices, objects, and servers in a platform-independent manner. SinceSOAP relies on HTTP as the transport mechanism, and most firewalls allowHTTP to pass through, SOAP endpoints may usually be invoked from eitherside of a firewall.

The client-side application 105 may transmit the database query (orinformation to form the database query) to the host server 108 alongwith the above-mentioned authentication information over a secureconnection. In such a scenario, the authentication information and thequery information may be passed to the DBMS 109. The DBMS 109 attemptsto authenticate the vendor and the consumer using the authenticationinformation and corresponding information that was previously stored inthe data repository 102. If authentication is successful, the DBMS 109queries the information account 110 using the appropriate databaseconnectivity protocol, such as the Open Database Connectivity (“ODBC”)protocol, the Java Database Connectivity Protocol (“JDBC”), or any othersuitable protocol.

As mentioned above, the data in the information account 110 may beencrypted. Thus, in response to the query, the DBMS 109 may receive anencrypted search result. The search result, for example, may be in theform of a stream of XML data that has been filtered from the informationaccount. The DBMS 109 or other program module executed by the hostserver 108 may be responsible for decrypting the search result. Thedecrypted search results may then be transmitted to the client-sideapplication 105 via the previously established or a new secureconnection.

In the alternative, the client-side application 105 may manageauthentication and querying as separate processes. As an example,authentication may be handled using a secure connection as describedabove. Upon acknowledgment of authentication, the secure connection maybe closed and the query process may be handled using open networkcommunication protocols. In response to the query, the encrypted searchresult may be transmitted to the client-side application 105 over theopen network and the client-side application 105 may be responsible fordecryption.

The client-side application 105 may also be responsible for parsing thedata elements included in the search result and auto-populating theparsed data into the input fields of the displayed web page file 116.Again, the client-side application 105 may translate the XML data intoHTTP data using SOAP or another suitable protocol. Those skilled in theart will appreciate that in certain embodiments, especially where userverification of the consumer information is not required, theclient-side application 105 may transmit the consumer informationdirectly to the vendor server 114 without populating the consumerinformation into the displayed web page file 116. If the input fieldsare auto-populated, the consumer has the opportunity to verify theinformation displayed in the input fields, make any necessarymodifications, and then interact with the displayed web page file 116 tosubmit the information to the vendor server 114. Any modifications tothe consumer information that are made by the consumer may be detectedby the client-side application 105, which may then transmit the modifieddata back to the host server 108 for an appropriate update of theinformation account 110. In addition, the client-side application 105may determine whether the consumer inputs new data into the inputfields, and if so, transmit that new information to the host server 108for storage in the data repository 102. The consumer may interact withthe displayed web page file 116 to submit the consumer information tothe vendor server 114. The vendor server 114 may then process theconsumer information, as needed, by way of a processing module.

In an alternative embodiment, a server-side application 107 may beemployed instead of a client-side application 105 to managecommunications with the host server 108. An authorized server-sideapplication 107 may receive consumer information directly from the hostserver 108 and present that consumer information to the client device104 (e.g., via the browser 112) for display to the consumer. A web pagefile 116 hosted by the vendor server 114 may be accessed and displayedby the browser 112 of the client device 104. The displayed web page file116 may present a user interface for input of consumer authenticationinformation. In a preferred embodiment, the consumer authenticationinformation is transmitted from the client device 104 to the host server108 for authentication of the consumer. In addition, the client device104 may also transmit a request that a “ticket” be provided to thevendor server 114.

As used herein, the term “ticket” refers to a temporary authorizationfor at least partial access to a consumer's information account 110.Although not shown in the figure, an information account 110 may beassociated with a data table or other data structure that correlates oneor more tickets with a set of consumer-defined attributes. Theconsumer-defined attributes may determine such things as the number oftimes that the password may be used to access the information account110 (e.g., one-time use), any period of validity associated with theticket (e.g., ticket expires one week from issuance), whether the ticketcarries read, write and/or modify privileges, etc. The ticket attributesmay also include any number of identifiers, such as a vendor identifier,a data identifier, and filter identifiers, which may be used to ensurethat the party using the ticket is in fact authorized to do so, and toensure that only authorized data is filtered for release to that party.

Upon authenticating the consumer, for example by using standard browserauthentication techniques, the host server 108 may redirect the browser112 of the client device 104 to another web page data file 116 (e.g.,another web page data file 116 hosted by of the vendor server 114),including the ticket as a parameter in the URL. In response to detectingthe ticket, the vendor server may extract the ticket and pass it to theserver-side application 107. The server-side application 107 may thenuse the ticket to authenticate itself to the host server 108, forexample using SOAP or another suitable protocol.

In accordance with one embodiment as described herein, a ticketgenerated by the host server 108 may be a “Globally Unique Identifier”(“GUID”). A GUID preferably comprises a unique number that is computedby adding the time and date to a network adapter's internal serialnumber, or by any other suitable technique. The ticket may be encrypted.For example, the ticket may be encrypted using the vendor's public keyand the resulting binary encrypted blob may be base64 encoded such thatso that it can be included as a parameter in a URL. At the vendor server114, the parameter may be extracted from the URL, base64 decoded andthen decrypted using the vendor's private key. Other encryptiontechniques may also be used.

In an alternative embodiment, consumer authentication information may besubmitted from the client device 104 to the server-side application 107at the vendor server 114. The server-side application 107 may thentransmit the consumer authentication information and vendorauthentication information to the host server 108 for authentication ofboth the consumer and the vendor. The consumer authenticationinformation may be encrypted at the client device 104 and decrypted onlyat the host server 108. Such an embodiment, however, places asignificant amount of control over the consumer's data in the hands ofthe vendor, and thus may not be preferable.

The server-side application may be identified by an applicationidentifier (“APPID”). The APPID may be associated at the host server 108(e.g., by the DBMS 109) with a particular filtering mechanism. Asmentioned, style sheets are well-known and highly suitable filteringtools for use in conjunction with XML data. In response toauthenticating the server-side application 107 and identifying theappropriate filter, consumer information may be filtered from theinformation account 110 and transmitted back to the server-sideapplication 107. The server-side application 107 may then parse theconsumer information, for example, in order to auto-populate a form,which may or may not have been previously displayed to the consumer.

As in the case of the client-side application 105, the server-sideapplication 107 may receive decrypted consumer information from the hostserver 108 via a secure connection, or may receive encrypted consumerinformation via the open network. Thus, the server-side application 107may be configured to perform decryption as necessary. The consumerinformation thus received from the host server 108 may be presented tothe consumer for verification. Any modifications or additions made tothe consumer information may be submitted back to the server-sideapplication 107 for communication to the host server 108. The DBMS 109may then update and/or create the information account 110 in theappropriate manner. The consumer may interact with the displayed webpage file 116 to submit the consumer information to the vendor server114. The vendor server 114 may then process the consumer information, asneeded, by way of a processing module.

Those skilled in the art will appreciate that the illustration anddiscussion of exemplary embodiments with reference to FIG. 1 is providedas a generalized example only. Specific details regarding data formatsand network communication protocols have been omitted, as such detailsare well known in the art. Furthermore, the present invention is notintended to be limited to the use of any particular data formats orprotocols. Any existing or future formats or protocols may be usedwithout departing from the spirit and scope of the invention.Furthermore, many network components were not shown or discussed withreference to FIG. 1, such as gateways, routers, hubs, switches,firewalls, DNS servers, authentication servers, certificate authorities,and the like. The functions and roles of such network components arealso well known in the art and need not be described in detail herein.

FIG. 2 provides an abstract illustration of an information account 110in accordance with an exemplary embodiment as described herein. In theillustrated embodiment, the consumer information is stored in theinformation account 110 as a single tagged (delimited) data stream. XMLgenerally provides a suitable tagged data format; however, other taggeddata formats can be employed as well. Thus, references to the XMLstandard in connection with exemplary embodiments are not intended tolimit the scope of the present invention. The single XML data streamcomprises a plurality of consumer information elements 202, each havinga unique tag 204 or identifier. A consumer information element 202 maybe divided into any number and/or level of sub-elements 206. As is wellknown in the art, an XML consumer information element 202 may also beassociated with one or more attributes 208. An attribute 208 may provideadditional information about the content, structure or formatting of aconsumer information element 202.

A consumer information element 202 may comprise any type of data orinformation, including text strings, objects, files, applications, etc.Obviously, the more consumer information that is stored in theinformation account 110, the larger the XML data stream will be. Thesize of the XML data stream is limited only by the hardware and softwarelimitations of the system (e.g., memory size, processor speed,bandwidth, etc).

An information account 110 is preferably unique to a single customer.Each information account 110 stored in the data repository 102 may thuscomprise a discrete XML data stream. Each information account 110 storedin the data repository 102 may be individually encrypted. For example,one method for encrypting an information account 110 may involve use ofthe consumer's public key. Accordingly, only someone having access tothe consumer's private key will be able to decrypt the consumer'sinformation. Many other and/or additional methods for encryptinginformation accounts 110 and/or the entire data repository 102 willoccur to those skilled in the art.

Although not shown in FIG. 2, those skilled in the art will appreciatethat a consumer information element 202 in one information account 110may comprise a pointer or a reference to another data element or toanother information account 110. In one embodiment, a consumer maycreate, for example, a list of business contacts. A new informationaccount may be created for each individual specified as a businesscontact by the consumer. Authentication data within the new informationaccount may be set as “anonymous” so that the first consumer may retainaccess privileges. At some point later, however, the individual named asthe business contact may be given control of the new information accountby changing the associated authentication information to be unique tothat individual. The first consumer may then be granted limited accessprivileges to continue to access the new information account of thebusiness contact (e.g., by way of a ticket). Alternatively, the firstconsumer may retain a copy of the business contact information in hisown information account.

FIG. 3 provides an abstract illustration of an information account 110in accordance with other exemplary embodiments of the present invention.In the embodiment shown, an information account 110 is structured asmultiple discrete XML aggregates 302 a-c. The discrete XML aggregates302 a-c may comprise one primary “profile” record 302 a and one or moreinformation product records 302 b-e. The profile record 302 a mayinclude a general profile of information elements 304 associated withthe consumer. Information product records 302 b-c contain consumerinformation elements that, for example, are specific to a particularproduct or service offered by a vendor, or that are important to vendorswith similar consumer information needs. Aggregation of data elementsaccording to information products allows quick and efficient retrievalof specific consumer information from the information account 110through a request-response system.

The number of aggregates or records included within the informationaccount 110 of a given consumer depends upon the number of informationproducts for which the consumer has elected to store information. Forexample, a consumer who has elected to store information about twoseparate products, such as a car loan and a mortgage loan, would have atleast three data aggregates in his information account 110. One suchdata aggregate would represent the primary profile record and each ofthe two other data aggregates would include information about one of theinformation products. Data aggregates may include but are not limited tothe following information products: Home Loan, Auto Loan, Student Loan,Home Insurance, Auto Insurance, Life Insurance, Online Banking, CreditCard, Government Services, Education, Career, Travel, Retail, andRelocation. If a consumer creates or updates an information account viaa vendor's web site and thereby inputs information regarding a newproduct, a new product record 302 b-c will be created in the informationaccount. Each product record 302 b-c created for the consumer is ofcourse associated with the primary profile record 302 a.

If an information account 110 is segmented into multiple discrete dataaggregates, there may be a need for maintaining consistency amongredundant data elements stored in multiple information products. “Latentreferential processing” is one method for maintaining data consistency,and in this context refers to the use of a series of pointers orreferences to flag data that is redundant across multiple products.According to latent referential processing, when a record 302 a-c iscreated or updated, redundant information elements that are stored inother data aggregates typically are not also updated until the next timethe information account is accessed. For example, if salary informationis updated in a home loan information product record, redundant salaryinformation in the consumer's auto loan information product record willgenerally not be immediately updated. Thus, latent referentialprocessing allows data inconsistencies to exist within the informationaccount after an update.

As is shown and described with reference to FIG. 4, a transaction log(e.g., a time stamp log) may be maintained for each redundantly storedaggregate in the information account to record the date and time of themost recent update for each data record 302 a-c. Each time a request ismade to access the information account, the DBMS 109 may first examinethe time stamp log to determine which data element in a set of redundantdata elements has most recently been updated. After determining the mostrecently updated data element, all other redundant data elements areupdated to be consistent with the most recently updated data element.Upon completion of the latent referential processing, the request toaccess the information account may be granted. Accordingly, latentreferential processing is a new way of storing and tracking informationthat addresses the need of providing quick access to information thatwill be accessed more frequently than it will be updated.

In another embodiment, redundancy and consistency concerns are addressedby normalizing the data aggregates of the information account 110 to theextent possible. For example, an information account 110 may beconfigured such that the consumer's profile record 302 a stores themajority of the consumer's personal information. The profile record 302a may comprise predefined data elements, such as “first name,” “middlename,” “last name,” date of birth,” etc. The profile aggregate 302 a mayalso be expanded to include any additional and/or custom fields.Additional aggregates corresponding to information products 302 c maycontain pointers 306 to the data fields within the profile aggregate 302a. Thus, the information account 110 may be configured to store withinone aggregate a single instance of an information element that isreferenced by other aggregates. As information product aggregates 302 care formed independently of the profile aggregate 302 a, data elementsthat are not unique to those information product aggregates 302 c may beported into the profile aggregate 302 a if desired.

FIG. 4 illustrates an exemplary database schema 400 in accordance withone or more exemplary embodiments as disclosed herein. In particular,the database schema 400 represents the situation where the informationaccount 110 is segmented into multiple discrete data aggregates, asshown in FIG. 3. The database schema 400 may include a consumerauthentication record 402 that stores consumer authenticationinformation 404 such as, for example, a user ID, username, password,email address, access attempts, last attempt date/time, challenge wordor phrase, challenge response, ticket parameters, and vendor creditedwith origination of the information account. These and other types ofauthentication information may be used to authenticate a consumer. Thedatabase schema 400 may also include a profile record 302 a that storesa primary information profile 304 of the consumer. There will typicallybe a one to one relationship between the consumer authentication table402 and the profile record 302 a. The exemplary database schema 400 alsoincludes one or more information product records 302 b-c that storeproduct-specific information. Each profile record 302 a may beassociated with one or many information product records 302 b-c.

The profile record 302 a and each information product record 302 b-c mayfurther be associated with a transaction log record 406. Each time theprofile record 302 a or an information product record 302 b-c is actedupon, detailed transaction information 408 may be recorded in a newtransaction log record 406 (not to be confused with the above-mentionedtime stamp log.) Transaction information 408 may provide the basis forall transaction billing and revenue sharing events. By way of exampleonly, the transaction record 406 may identify the vendor server throughwhich the information account 110 was created. The transaction record406 may also identify the vendor server through which a transaction wascompleted using the information account 110.

As used herein, the term “transaction” refers broadly to any activityrelated to an information account, including, but not limited to acreate transaction, delete transaction, update transaction,authentication transaction, a request for information from authorizedvendors, a client device and/or vendor server 114 request, a publishingand form filling transaction, and a submit transaction where theinformation account 110 is processed into the requesting vendorssystems. A portion of any monies billed upon completion of a transactionmay be shared with each of the vendor servers identified in thetransaction record 406.

FIG. 5. is a generalized interaction diagram illustrating theinteraction between various system components of certain exemplaryembodiments in connection with consumer-controlled storing, managingand/or distributing information. The exemplary embodiments discussedwith reference to FIG. 5 employ a client-side application 105, such asan applet, to manage communication between the client device 104 and thehost server 108. Alternative embodiments employing a server-sideapplication 107 instead of the client-side application 105 have beendiscussed above. Those skilled in the art will appreciate thedifferences between the interactions involving a client-side application105 and a server-side application 107.

The generalized interaction diagram begins at step 501, where theconsumer operates a browser 112 to retrieve a web page file 116 from thevendor server 114 via the network 106, using a consumer browser. The webpage file 116 retrieved from the vendor server 114 may be enabled forinteraction with the consumer's information account 110 and may thusinclude an instruction that causes the browser 112 to download aclient-side application from the host server 108. At step 502, theclient-side application is downloaded from the host server 108 to thebrowser 112. At step 504, the consumer interacts with the browser 112 torequest use of the information account 110, which in this example hasalready been created. The web page file 116 may display a selectableicon or other indicia that allows the consumer to request use of theinformation account 110. Alternatively, the client-side application 105may provide the interface for requesting use of the information account110.

Next at step 506, the client-side application 105 displays a logininterface to the consumer. The login interface may be displayed, forexample, in the open display window of the browser 112, in a pop-upwindow, or in any other suitable manner. At step 508 the consumer inputsconsumer authentication information, which is transferred from thebrowser to the client-side application 105. Consumer authenticationinformation may comprise, for example, a username, user ID, password,challenge phrase, email address, etc. At step 510, the userauthentication information is combined with vendor authenticationinformation and is sent to the DBMS 109. Vendor authenticationinformation may comprise a vendor ID, password, product IP, applicationID, and the like. Vendor authentication information may be used toauthenticate the vendor and to determine the manner in which consumerinformation is to be filtered from the information account 110.

After the DBMS 109 receives the authentication information, it submitsan authentication request to the data repository 102 at step 512. Theauthentication request may be a database query to determine if thesupplied consumer authentication information and vendor authenticationinformation are consistent with previously stored authenticationinformation. In response to authenticating the consumer and the vendor,the DBMS 109 performs one or more database queries at step 514 toretrieve consumer information elements from the information account 110.Depending on the structure of the information account, the DBMS 109 mayretrieve certain products (identified by product ID) from theinformation account 110, or may retrieve a set of data elements filteredaccording to a vendor ID or an application ID. If consumer informationis retrieved according to products, an iterative lightweight transfer(“LWT”) process may be performed in order to get the best set of dataelements for each new product ID. Lightweight transfer techniques arewell-known in the art and generally involve the use of thin protocolsand/or smart proxies that can cache results and perform buffered readsand writes, minimizing the number of network calls.

Once the DBMS 109 has retrieved the relevant consumer information, theconsumer information elements may be merged (if appropriate) decrypted(if appropriate) and/or further filtered (if appropriate) at step 518.Then, at step 520, the resulting information elements are transmitted tothe client-side application 105, for example in the form of an XML datastream. At step 522, the client-side application 105 parses the receivedXML data and transforms it into the required format for populating theinput fields of the displayed web page file 116. The client-sideapplication 105 then auto-populates the input fields of the displayedweb-page file 116 at step 524. The consumer may interact with thebrowser 112 to edit or modify the auto-populated information at step526. Because there may be multiple web page files 116 associated withthe vendor website, steps 524 and 526 are repeated until all data hasbeen auto-populated and/or edited on every included web page. Theclient-side application 105 monitors the edit process to determine ifthe consumer desires to modify and/or supplement any of the consumerinformation elements.

The consumer may then interact with the browser 112 at step 528 in orderto submit the consumer information that has been entered into thedisplayed web page file(s) 116 to the vendor server 114. The vendorserver 114 receives and processes the consumer information elements atstep 530. After processing the consumer information, the vendor server114 preferably transmits a “success page” or other acknowledgement tothe consumer's browser 112 at step 532.

Either through a selectable icon or other indicia displayed on thesuccess page or displayed by the client-side application 105, or anyother interactive means, the consumer may interact with the browser 112at step 534 to submit an update request to the DBMS 109. Update is anevent whereby the information account 110 is updated to reflect anyedits that the consumer may have made to the consumer information atstep 526. Thus, a consumer is permitted to update the informationaccount 110 via a vendor's website. As another option, the consumer mayelect to update the information account 110 at a later time directly viathe host server 108.

At step 536 the client-side application submits the consumer's XML data(possibly only the edited data) and the update request to the DBMS 109.Then at step 538 the update request is submitted to the data repositoryfor authentication. In the authentication process, consumerauthentication information, vendor authentication information and, ifappropriate, product identification information (which are all includedin the update request) are verified. Upon authentication of the updaterequest, the XML data is validated at step 540 and the update isperformed at step 542. The DBMS then sends the update result (success orfailure) to the client-side application 105 at step 544, which in turndisplays the update result to the browser 112 at step 546. The exemplarygeneralized interaction diagram then ends at step 548.

FIG. 6 is a generalized interaction diagram illustrating the interactionbetween main system components when a new information account is createdby a consumer via a vendor's website. As mentioned, the consumer maycreate an information account by visiting a vendor's website that hasbeen configured to allow creation of an information account. Thevendor's website may, for example, require the user to manually inputconsumer information into the input fields of a form. The user may thendirect that an information account be created to store the consumerinformation, so that the consumer will not be required to manually enterthe consumer information again on any participating website.

The exemplary embodiments discussed with reference to FIG. 6 employ aclient-side application 105, such as an applet, to manage communicationbetween the client device 104 and the host server 108. Alternativeembodiments employing a server-side application 107 instead of theclient-side application 105 have been discussed above. Those skilled inthe art will appreciate the differences between the interactionsinvolving a client-side application 105 and a server-side application107.

The exemplary interaction diagram of FIG. 6 begins at step 601, wherethe consumer operates a browser 112 to retrieve a web page file 116 fromthe vendor server 114 via the network 106, using a consumer browser. Theweb page file 116 retrieved from the vendor server 114 may be enabledfor interaction with the consumer's information account 110 and may thusinclude an instruction that causes the browser 112 to download aclient-side application from the host server 108. At step 602, theclient-side application is downloaded from the host server 108 to thebrowser 112. At step 604, the consumer interacts with the browser 112 toinput consumer information into the input fields of the vendor'swebsite. The client-side application 105 monitors the input of consumerinformation at step 606.

Next at step 608 the consumer interacts with the browser 112 in order tosubmit the consumer information to the vendor server 114. The vendorserver 114 receives and processes the consumer information elements atstep 610. After processing the consumer information, the vendor server114 transmits a “success page” or other acknowledgement to theconsumer's browser 112 at step 612. Either through a selectable icon orother indicia displayed on the success page or displayed by theclient-side application 105, the consumer may interact with the browser112 at step 614 to submit a request for creation of an informationaccount 110 to the DBMS 109. Thus, the consumer may be permitted tocreate an information account 110 via a vendor's website. As anotheroption, the consumer may elect to create an information account 110 at alater time directly via the host server 108.

At step 616 the client-side application submits the consumer's XML dataand the create request to the host server 108. Then at step 618 the hostserver 108 transmits an information account creation interface to thebrowser 112. The consumer inputs consumer authentication information viathe information account creation interface at step 622 and the browser112 passes the create request (which may include the consumerauthentication information, the vendor authentication information, etc.)to the client-side application 105 at step 624.

At step 626, the create request is combined with the consumer's XML dataand is sent to the DBMS 109. In response to receiving the authenticationinformation, the DBMS 109 submits an authentication request to the datarepository 102 at step 628. The authentication request may be a databasequery to determine if the supplied consumer authentication informationand vendor authentication information are consistent with previouslystored authentication information. In response to authenticating theconsumer and the vendor, the DBMS 109 validates the consumer's XML dataat step 630 and creates a new information account 110 at step 632.

Once the information account has been created, the DBMS 109 sends thecreate result (success or failure) to the client-side application 105 atstep 634, which in turn displays the create result to the browser 112 atstep 636. At step 638, the host server 108 creates an acknowledgmentemail to be sent to the consumer's email account. At step 640, the hostserver requests and receives the consumer's email address from the DBMS109. At step 642 the consumer's acknowledgment email is delivered to theconsumer. The exemplary generalized interaction diagram then ends atstep 644.

FIG. 7 is a generalized interaction diagram illustrating the interactionbetween various system components in an exemplary wireless environmentsuitable for implementation of systems or methods forconsumer-controlled storage, management and/or distribution ofinformation. An exemplary wireless environment is suited for wirelessdevices such as digital or cellular telephones, personal digitalassistants (“PDAs”), portable computers, and the like. Such wirelessdevices generally include a display device and an input device (keypad,touch screen, microphone, etc.), each of limited size and utility. Thedifficulty of inputting detailed information and commands into awireless device makes it desirable to provide a system whereby thebackend DBMS 109 is able to communicate directly with various remote webservers, thus eliminating a significant amount of user-interaction withthe wireless device.

The generalized interaction diagram of FIG. 7 begins at step 701, wherethe consumer operates a wireless client device 104 a to access the hostserver 108. Accessing the host server 108 may involve, for example,calling a dedicated access number using a mobile telephone device ortwo-way pager. At step 702, the wireless client device 104 a accessesthe host server 108 via a wireless application (“WAP”) gateway. At step704, the host server 108 returns a login interface to the wirelessclient device 104 a. At step 706 the consumer inputs consumerauthentication information using an input device of the wireless clientdevice 104 a. Consumer authentication information may comprise, forexample, a username, user ID, password, challenge phrase, email address,etc.

At step 708, the user authentication information is combined with vendorauthentication and is sent to the DBMS 109. Vendor authenticationinformation may comprise a vendor ID, password, product IP, applicationID, and the like. Vendor authentication information may be used toauthenticate the vendor and to determine the manner in which consumerinformation is to be filtered from the information account 110. Afterthe DBMS 109 receives the authentication information, it submits anauthentication request to the data repository 102 at step 710. Inresponse to authenticating the consumer and the vendor, the DBMS 109performs one or more database queries to retrieve consumer informationelements from the information account 110. Depending on the structure ofthe information account, the DBMS 109 may retrieve certain products(identified by product ID) from the information account 110, or mayretrieve a set of data elements filtered according to a vendor ID or anapplication ID. If consumer information is retrieved according toproducts, an iterative lightweight transfer (“LWT”) process may beperformed at step 712 in order to get the best set of data elements foreach new product ID. Otherwise, the consumer information elements areretrieved from the data repository 102 using appropriate filters at step714.

Once the DBMS 109 has retrieved the relevant consumer information, theconsumer information elements may be merged (if appropriate), decrypted(if appropriate) and/or further filtered (if appropriate) at step 716.Then, at step 718, the resulting information elements are transmitted tothe vendor server 114, for example, in the form of an XML data stream.The vendor server 114 receives and processes the consumer informationelements at step 720. After processing the consumer information, thevendor server 114 transmits a delivery receipt acknowledgment to thehost server 108 at step 722. The host server 108 may then pass anacknowledgment (success or failure) to the consumer (e.g., to thewireless client device 104 a or to another client device 104) at step724. The exemplary generalized interaction diagram then ends at step726.

As shown in FIG. 8, information accounts 110 may be used in the contextof one or more exchanges 802A&B. In this context, an exchange 802A&B maycomprises a group of entities (e.g., vendor servers 114) that areauthorized and configured to accept consumer information from aparticular information account 110 at the request of the consumer. Aninformation account 110 may, in some embodiments, be used to retrieveinformation for use in commerce with any vendor that is a member of theexchange 802A&B. An information account 110 may be accepted in one ormore exchanges 802A&B according to various rules and relationships, asillustrated by the examples set forth herein. A consumer may also haveseveral different information accounts 110, each valid for use in one ormore exchanges.

An exchange may comprise a logical grouping of servers or other networkdevices, and those skilled in the art will appreciate that there are avariety of suitable methods for implementing logical groupings ofnetwork devices on a distributed network. For example, an exchangeidentifier may be used to identify an exchange and may be associatedwith each network device that is a member of that exchange. In such anembodiment, a look-up table of exchange identifiers may be maintained atthe host server 108, within the central data repository 102 or atanother suitable location and may be used to authenticate an exchangeidentifier used in connection with a request for access to aninformation account 110.

Exchanges 802A&B may be implemented, for example, through inflow and/oroutflow constraints. An inflow constraint may, for example, dictate thatonly information accounts 110 associated with specific other exchangeswill be accepted within an exchange or that no information accounts 110associated with other exchanges will be accepted. An outflow constraintmay dictate that information accounts 110 associated with an exchangemay be used within that exchange and within no other exchanges (i.e., aprivate exchange), or within only selected other exchanges. Variousbusiness situations and partnerships may drive the implementation ofinflow and outflow constraints.

In various embodiments, an information account 110 may be branded so asto be associated with a particular vendor or other entity, product orservice. By way of example only, if a consumer creates an informationaccount 110 via a website maintained on behalf of a particular vendor,e.g., “Vendor X,” the information account 110 may be branded as a“BrandX” information account 110X. A BrandX information account 110X maybe stored in the central data repository in association with a BrandXidentifier. BrandX logos or indicia may be displayed to the consumerwhen the consumer accesses the BrandX information account 110X. Thus,although Vendor X “sponsors” the BrandX information account 110X, thecentral data repository 102 that stores the BrandX information account110X may be maintained by another entity.

An exchange 802A&B may be configured to accept one or more differentlybranded information accounts 110. This concept is similar to automatedteller machine (ATM) networks, in which a customer of one bank may usehis ATM card (e.g., debit or credit card) to conduct transactions at theATM of another bank. Typically, an ATM card includes a number of logos(also referred to as “bugs”) that indicate the financial networks thatwill accept the ATM card. ATMs also display logos identifying thefinancial networks to which they are connected. Thus, a bank customermay have a Wachovia® ATM card that is accepted in all Honor and PLUSnetwork ATMs. Similarly, the various vendor servers 114 that make up aparticular exchange may include logos or other indicia indicating thebrands of information accounts 110 that will be accepted.

With reference to FIG. 8 and FIG. 9, a consumer interacting with abrowser 112 of a client device 104 may be presented with a web page file116Y by a vendor server 114Y maintained by Vendor Y. The displayed webpage file 116Y may display an enrollment application link 902 that, whenselected, will cause an enrollment application to be presented to theconsumer. An enrollment application may be a form or other interfacethat prompts the consumer to input selected information. The website ofVendor Y may be configured, as described above, for interaction with thecentral data repository 102 via the host server 108. Furthermore, thevendor server 114Y may be a member of “Exchange B” 802B that alsoincludes vendor server Z 114Z. For the sake of example only, it may beassumed that the inflow constraints of Exchange B 802B allow any membervendor server (114Y&Z) to accept BrandY information accounts 110Y,BrandZ information accounts 110Z and BrandX information accounts 110X.

The displayed web page file 116Y may thus display one or more brandlogos 904 indicating the accepted brands of information accounts. Thedisplayed web page file 116Y may also display one or more exchange logos906 indicating the exchanges of which the vendor server 114Y is amember. In addition, the displayed web page file 116Y may display anaccess/create link 908 for allowing a consumer to access or create aBrandY information account 110Y. The displayed web page file 116Y ofFIG. 9 is shown by way of example only and many other arrangements arepossible. In perhaps a more practical example, the brand logos 904, theexchange logos 906 and the access/create link 908 might be presented tothe consumer only if the consumer selects the enrollment applicationlink 902. Other types of user interfaces may also be used.

When used in the context of a private exchange (e.g., an exchange thatdoes not accept foreign information accounts 110) an information accountmay take the form of a “private” branded information account 110. As anexample, if Vendor X establishes a private Exchange A 802A that offers avariety of financial services, a BrandX information account 110X may beestablished for consumers who participate in the private exchange. TheBrandX information account 110X may be configured to store informationthat is relevant to the financial services offered by Vendor X. Ifappropriate outflow constraints are established, the BrandX informationaccount 110X may be accepted only within private Exchange A 802A. Again,Vendor X may facilitate or otherwise sponsor the creation of the BrandXinformation account 110X, while another entity may server as thecustodian of the data repository 102 for storing the BrandX informationaccount 110X and provide the underlying information technology.

If private Exchange A 802A is not subject to outflow constraints, aBrandX information account 110X may also be accessed at websites hostedby or on behalf of other vendors, such as Vendor Y and/or Vendor Z.Consequently, an on-line form associated with Vendor Y web page files116Y or Vendor Z web page files 116Z may automatically be populatedbased on information elements originating from the BrandX informationaccount 110X. Similarly, if Exchange A 802A is subject to appropriateinflow constraints, a BrandY information account 110Y and a BrandZinformation account 110Z may also be used at any website hosted by avendor server 114X that is a member of the Exchange A 802A. In general,any number of vendors or other entities may participate in an exchange.

Various licensing arrangements and revenue sharing agreements may beestablished between the custodian of the data repository 102 and thevendors that configure their vendor servers 114 for interaction withinformation accounts 110. In particular, the custodian may choose toimplement revenue sharing models in order to provide vendors with anincentive to promote and facilitate the creation and use of informationaccounts 110. The custodian may earn revenues in exchange for theservice of providing access to information accounts 110 for completionof transactions. For example, the custodian may be paid a pertransaction commission by the requesting exchange or vendor each time aninformation account 110 is used by a consumer to quickly fill out a formor other document for completing a transaction with a vendor. As anotherexample, the custodian of the data repository 102 may receive revenuefrom the requesting exchange or vendor based on milestone transactionnumbers. For example, the custodian may be paid a negotiated dollaramount for a negotiated number of transactions (e.g., $100 for every 500transactions completed using an information account).

The more information accounts 110 that are in existence, the moretransactions that are likely to occur in commerce. Accordingly, thecustodian of the data repository 102 may choose to implement variousrevenue sharing models in order to financially encourage vendors andother entities to promote and/or sponsor information accounts 110. As anexample, a revenue sharing model may specify that a lifetime revenuestream be paid to the originating vendor or entity that is credited withfacilitating the creation of an information account 110. A lifetimerevenue stream may be effective for the life of the information account110 and may take the form of a credit issued to the originating vendoror entity each time that information account 110 is used to complete atransaction. A credit may amount to a percentage (anywhere from 0% to100%) of the revenue earned by the custodian of the data repository 102in connection with the transaction, or an otherwise arranged fee.Revenue sharing models may also specify that credits be paid by thecustodian of the data repository 102 to a transacting vendor or entitythat accepts consumer information elements from an information account110 in order to complete a transaction.

In the context of exchanges and branded information accounts, theamounts credited to originating entities and transacting entities mayvary depending on the particular exchange and/or which brand of brandedinformation account was used in order to complete a transaction. Forexample, referring back to FIG. 9, the custodian of the central datarepository 102 may grant larger credits to a transacting vendor (VendorX) when a BrandY information account 110Y (that is, an informationaccount from another exchange) is used to complete a transaction throughthe vendor server 114X, as opposed to when a BrandX information account110X (that is, an information account from the same exchange) is used tocomplete a transaction through the vendor server. As mentioned, anynumber of factors or business relationships may affect the revenuesharing models adopted by the custodian of the central data repository102. As will be appreciated by those of skill in the art, differentand/or multiple revenue sharing models may be applied to differentexchanges or associated with differently branded information accounts.Members of an exchange may also choose to establish their own additionalrevenue sharing models, for example, in an attempt to maximize theacceptance of a branded information account.

Revenue sharing models may further include credits paid to OEMs,consultants, software providers and/or any other party who facilitatesthe creation and/or construction of an exchange, introduces informationaccounts 110 to an exchange, or otherwise assists the custodian of thecentral data repository 102 in increasing its revenue base.

FIG. 10 is an abstract illustration of system components forimplementing revenue sharing models in accordance with certain exemplaryembodiments as disclosed herein. As shown, the central data repository102 may store one or more transaction logs 1002 containing informationrelevant to any transaction that involved an information account 110.The transaction log 1002 may identify, for example, the date, time andnature of the transaction, the originating entity, the transactingentity, whether the information account 110 was branded, etc. Manyalternatives for storing and identifying transaction information arepossible in the context of the illustrated embodiment. For example, eachinformation account 110 may include or have associated therewith aunique transaction log 1002. Alternatively, a transaction log 1002 maybe used to store transaction information associated with multipleinformation accounts 110.

An extraction module 1004 may be used to facilitate the extraction oftransaction information from a transaction log 1002. The extractionmodule 1004 may be executed by the host server 108 or by another networkdevice that is in communication with the host server 108 or the centraldata repository 102. The extraction module 1004 may be employed toextract selected transaction information from the transaction log 1002and to translate or transform the extracted transaction information intoa format that can be interpreted by a financial processing system 1006.Thus, in certain embodiments, the extraction module 1004 may beconfigured to extract transaction data elements from a tagged datastream representing or associated with an information account 110. SOAPand/or other well-known protocols may be used by the extraction module1004 to interface between the transaction log 1002 and the financialprocessing system 1006. The financial processing system 1006 maycomprise any system for processing transaction information and revenuesharing models in order to ensure that the appropriate party is billedin connection with a transaction involving an information account andthat revenues are shared with the appropriate parties. By way of exampleonly, the financial processing system may be a custom software module oran off-the-shelf software package, such as the well-known “OracleFinancials” package.

Those skilled in the art will appreciate that the system components andarrangement thereof shown in FIG. 10 are by way of example only. Variousother methods for recording and processing transaction information maybe used in accordance with the concepts and principals discussed orsuggested herein.

From a reading of the description above pertaining to various exemplaryembodiments, many other modifications, features, embodiments andoperating environments of the present invention will become evident tothose of skill in the art. The features and aspects of the presentinvention have been described or depicted by way of example only and aretherefore not intended to be interpreted as required or essentialelements of the invention. It should be understood, therefore, that theforegoing relates only to certain exemplary embodiments of theinvention, and that numerous changes and additions may be made theretowithout departing from the spirit and scope of the invention as definedby any appended claims.

1. A method for managing information in an environment that includes ahost system, comprising: receiving, at the host system, a signal tomodify an electronic input interface; modifying the electronic inputinterface at the host system to indicate entry of consumer profileinformation corresponding to the signal; collecting, at the host system,the consumer profile information entered in the electronic inputinterface; transferring the collected consumer profile information fromthe host system to a data repository for storage in an informationaccount logically associated with an exchange, the exchange comprising agroup of one or more servers authorized and configured to accept theconsumer profile information from a particular information account uponrequest; receiving, at the host system, a request from the exchange forconsumer profile information associated with a specific informationaccount; and responding to the request at the host system by retrievingsome of the consumer profile information from the data repository andconveying the retrieved consumer profile information to the requestingexchange, provided that the information account storing the consumerprofile information is associated with the requesting exchange.
 2. Themethod of claim 1, wherein the electronic input interface comprises oneor more of a web-enabled form, and a web page file having an inputfield.
 3. The method of claim 1, wherein the request is initiated fromactivity at a client device that is in communication with the exchangeover the distributed network.
 4. The method of claim 1, furthercomprising maintaining a transaction log recording utilization of theinformation account to allow for compensation to an originating partywith whom the information account is associated.
 5. The method of claim1, further comprising encrypting some of the consumer profileinformation.
 6. The method of claim 5, further comprising decryptingsome of the encrypted consumer profile information.
 7. The method ofclaim 1, further comprising: receiving, at the host system, a queryrequest; causing a query of the data repository to be performedaccording to the query request; receiving query results; and providingthe query results.
 8. The method of claim 7, further comprising causingthe decryption of the query results.
 9. The method of claim 1, furthercomprising manipulating data elements in the information account basedon input received from the consumer.
 10. The method of claim 1, furthercomprising controlling, at the host device, access to the informationaccount.
 11. A tangible computer-readable medium having stored thereoncomputer-executable instructions that, if executed by a computingdevice, cause the computing device to perform at least a portion of themethod of claim
 1. 12. A system operable to perform the method of claim1, the system comprising: the host system; and the data repository wherethe information accounts are stored.
 13. A method for managinginformation in an environment that includes a client device, comprising:accessing, at the client device, an electronic input interface;transmitting, with the client device, a signal to a host systemassociated with the electronic input interface by entering consumerprofile information into the electronic input interface; requestingcreation of an information account for storage of the consumer profileinformation; receiving, at the client device, authentication informationfrom the host system; and enabling access to some of the consumerprofile information stored in the information account.
 14. The method ofclaim 13, wherein one or more of the accessing, transmitting, requestingand receiving processes is performed using wireless communication. 15.The method of claim 13, wherein enabling access to some of the consumerprofile information comprises transferring selected consumer profileinformation to the vendor, or allowing the vendor to access theinformation account.
 16. The method of claim 13, further comprisingtransmitting a request from the client device for authentication. 17.The method of claim 16, wherein transmitting a request from the clientdevice for authentication comprises signing on for authentication toaccess the information account.
 18. The method of claim 13, furthercomprising: formulating a database query based upon informationspecified by the electronic input interface; transmitting the databasequery; receiving search results generated in connection with performanceof the database query.
 19. The method of claim 18, further comprisingtranslating the received search results into another form according to apredefined protocol.
 20. The method of claim 19, wherein translating thereceived search results into another form according to a predefinedprotocol comprises translating XML data into HTTP data using SOAP. 21.The method of claim 13, wherein the client device executes a browser inorder to interact with the electronic input interface.
 22. A wirelesscommunication device that is programmed to perform at least a portion ofthe method of claim
 13. 23. The wireless communication device of claim22, wherein the wireless communication device comprises one of apersonal digital assistant (PDA), digital and/or cellular telephone orpager, a handheld computer, a mobile wireless communication device. 24.A method for data management, the method comprising: storing a consumerinformation account that comprises first and second data aggregates, thefirst data aggregate including a consumer information element thatconstitutes the same data as a consumer information element of thesecond data aggregate; flagging each of the consumer informationelements to indicate that both consumer information elements constitutethe same data; updating the consumer information element of the firstdata aggregate in response to a request; and delaying a correspondingupdate to the information element of the second data aggregate until thenext time the information account is accessed, so that a datainconsistency in the information account is allowed to exist for aperiod of time.
 25. The method of claim 24, further comprisingmaintaining a transaction log for each redundantly stored data aggregateto record the time and date of the most recent update for each dataaggregate.
 26. The method of claim 25, wherein: each time a request ismade to access the information account, the transaction log is firstexamined to determine which redundant data element was most recentlyupdated; all redundant data elements are updated to be consistent withthe redundant data element that was most recently updated; and therequest to access the information account is granted.
 27. The method ofclaim 24, wherein the first data aggregate represents a primary profilerecord of a consumer, and the second data aggregate includes informationabout an information product.
 28. A tangible computer-readable mediumhaving stored thereon computer-executable instructions that, if executedby a computing device, cause the computing device to perform at least aportion of the method of claim
 24. 29. A consumer information accountfor storing consumer information elements, comprising: a primary recordconfigured to store a plurality of general consumer information elementsabout a consumer; and one or more secondary records that each storeconsumer information elements that are specific to a particular productor service associated with a vendor, the one or more secondary recordsand the primary record being stored in a data repository accessible by adatabase management system.
 30. The consumer information account ofclaim 29, wherein each of the records is stored in a tagged data format.31. The consumer information account of claim 29, wherein each of therecords is represented by a data aggregate.
 32. The consumer informationaccount of claim 29, wherein one or more of the records are implementedas a discrete XML aggregate.
 33. The consumer information account ofclaim 29, wherein data aggregates representing the one or more secondaryrecords include one or more of Home Loan, Auto Loan, Student Loan, HomeInsurance, Auto Insurance, Life Insurance, Online Banking, Credit Card,Government Services, Education, Career, Travel, Retail, and Relocation.34. The consumer information account of claim 29, wherein the consumerinformation account is modifiable to include additional records.
 35. Aserver programmed to manage consumer information, the server comprising:a database management system programmed to: receive, from one or morenetwork devices, requests for access to a plurality of consumerinformation accounts stored in a data repository accessible to thedatabase management system, each request including consumerauthentication information; authenticate or deny each request based onthe consumer authentication information; and for each authenticatedrequest, transmit one or more consumer information elements from thecorresponding consumer information account to the requesting networkdevice; a first authentication table including data that correlates eachof one or more temporary authorizations with a different set ofconsumer-defined attributes, each of the different set ofconsumer-defined attributes defining access privileges to acorresponding consumer information account that will be granted to anentity that presents the temporary authorization to the host server; andan authentication module programmed to: compare each temporaryauthorization presented to the host server to the data in the firstauthentication table to determine a level of access to grant to theentity that presents the temporary authorization; and grant the level ofaccess subsequent to receipt of the temporary authorization.
 36. Theserver of claim 35, wherein the database management system is programmedto formulate and perform a database query based upon informationreceived.
 37. The server of claim 36, wherein the database managementsystem is programmed to perform the query only after an authenticationprocess has been performed by the database management system.
 38. Theserver of claim 35, wherein the database management system is programmedto decrypt a search result obtained in connection with performance of adatabase query.
 39. The server of claim 35, wherein the search result isin the form of XML data filtered from an information account.
 40. Asystem comprising: a transaction log stored in a data repository andassociated with one or more consumer information accounts stored in thedata repository, wherein the transaction log records informationrelevant to transactions that involve the one or more associatedconsumer information accounts; and an extraction module programmed toextract transaction information from the transaction log and translatethe extracted transaction information into a format that can beinterpreted by a financial processing system; wherein the system isconfigured to process the transaction information to ensure that revenuegenerated by a transaction that involves one of the one or moreassociated consumer information accounts is shared with an entity thatfacilitated creation of the one of the one or more associated consumerinformation accounts.
 41. The system of claim 40, wherein the extractionmodule is programmed to extract transaction data elements from a taggeddata stream.
 42. The system of claim 40, wherein the extraction moduleuses the SOAP protocol to interface between the transaction log and thefinancial processing system.
 43. A method, comprising: storing consumerprofile information in each of a plurality of information accounts onbehalf of a plurality of exchanges, each of said exchanges comprising alogical grouping of one or more servers communicating with user devicesover a distributed network, and each information account beingaffiliated with at least one of said exchanges; applying atransformation mechanism to data in one or more information accounts sothat only specified data elements are extracted from the informationaccount; retrieving the specified data elements from the consumerprofile information and conveying the retrieved data elements to saidexchanges in response to requests from servers within said exchangesresulting from consumer-initiated requests requiring use of the consumerprofile information; and imposing fees for conveying consumer profileinformation to the exchanges.
 44. The method of claim 43, whereinimposing fees for conveying consumer profile information to theexchanges comprises imposing a fixed or varying fee for each transactioninvolving conveyance of consumer profile information to the exchanges.45. The method of claim 43, wherein imposing fees for conveying consumerprofile information to the exchanges comprises imposing a fixed orvarying fee for each group of transactions involving conveyance ofconsumer profile information to the exchanges.
 46. The method of claim43, further comprising: an obtaining consumer profile informationthrough the servers of said exchanges, and creating new informationaccounts thereby; identifying an originating vendor or entity each timea new information account is created; and compensating the originatingvendor or entity for each transaction involving conveyance of consumerprofile information from an information account identified with theoriginating vendor or entity.
 47. The method of claim 46, whereincompensating the originating vendor or entity for each transactioninvolving conveyance of consumer profile information comprises providingthe originating vendor or entity with a credit against any fee imposedfor conveying consumer profile information on behalf of the vendor orentity.
 48. The method of claim 46, wherein imposing fees for conveyingconsumer profile information to the exchanges comprises: imposing afirst fixed or varying fee for each transaction involving conveyance ofconsumer profile information to an exchange associated with theoriginating vendor or entity of the information account storing theconsumer profile information; and imposing a second fixed or varyingfee, higher than said first fixed or varying fee, for each transactioninvolving conveyance of consumer profile information to an exchange notassociated with the originating vendor or entity.
 49. A method,comprising: gathering consumer profile information at each of aplurality of exchanges, each exchange comprising a logical grouping ofone or more servers communicating with user devices over a distributednetwork; normalizing some of the consumer profile information into aplurality of discrete data aggregates; sending, from each exchange andover the distributed network, the normalized consumer profileinformation to a shared data repository for storage in informationaccounts associated with the originating exchange; and receiving, ateach exchange, normalized consumer profile information from theexchange's shared data repository in response to consumer-initiatedrequests requiring use of the consumer profile information.
 50. A methodfor managing consumer information, comprising: storing a brandedinformation account in a data repository accessible via a distributednetwork, the branded information account comprising a plurality ofconsumer information elements associated with a consumer and identifyinga sponsor of the branded information account; receiving, over thedistributed network, a request from a network device for one or moreselected consumer information elements, the request including consumerauthentication information and being made by the network deviceresponsive to an input command; and in response to the request:performing an authentication process using the authenticationinformation; retrieving the selected consumer information elements fromthe branded information account, wherein retrieving the selectedconsumer information elements includes applying a transformationmechanism to data in the branded information account so that only therequested consumer information elements are extracted from theinformation account; and transmitting the selected consumer informationelements, over the distributed network, to the network device.
 51. Themethod of claim 50, wherein the sponsor of the branded informationaccount comprises a vendor or entity that facilitated creation of thebranded information account.
 52. A tangible computer-readable mediumhaving stored thereon computer-executable instructions that, if executedby a computing device, cause the computing device to perform at least aportion of the method of claim
 50. 53. The method of claim 50, whereinthe network device comprises a vendor server operable to interact with aclient device, the vendor server operable to execute a server-sideapplication for interacting with a database management system thatmanages the data repository, and wherein: the vendor server is a memberof an exchange comprising a logical grouping of servers authorized tointeract with branded information accounts; the request further includesan exchange identifier for identifying the exchange; and in response tothe request, the exchange identifier is authenticated to ensure that theexchange is authorized to interact with the branded information account,prior to transmitting the selected consumer information elements to thenetwork device.
 54. The method of claim 53, wherein the brandedinformation account is valid only within the exchange and not within anyother exchanges.
 55. The method of claim 53, wherein the brandedinformation account is valid within the exchange and within at least oneother specified exchange.
 56. The method of claim 53, wherein theserver-side application receives the selected consumer informationelements from the database management system and integrates the selectedconsumer information elements into a business process on behalf of theconsumer.
 57. A tangible computer-readable medium having stored thereoncomputer-executable instructions that, if executed by a computingdevice, cause the computing device to perform at least a portion of themethod of claim
 56. 58. The method of claim 56, wherein integrating theselected consumer information elements into the business processcomprises: auto-populating the selected consumer information elementsinto at least one input field of an editable web page file; transmittingthe auto-populated web page file to the client device for display to theconsumer; in response to a submit command received from the clientdevice, passing the selected consumer information elements to aprocessing module executed by the vendor server; and transmitting anyedited or added consumer information elements to the database managementsystem for appropriate updating of the branded information account. 59.A tangible computer-readable medium having stored thereoncomputer-executable instructions that, if executed by a computingdevice, cause the computing device to perform at least a portion of themethod of claim
 58. 60. The method of claim 50, wherein the networkdevice comprises a client device executing a browser for interactingwith a web page file hosted by a vendor server, and wherein: the webpage file includes an instruction that causes the browser to requesttransmission of a temporary client-side application configured to managethe request/response process for the client device; the vendor server isa member of an exchange comprising a logical grouping of serversauthorized to interact with one or more branded information accounts;the request from the network device further includes an exchangeidentifier for identifying the exchange; and in response to the request,the exchange identifier is authenticated to ensure that the exchange isauthorized to interact with the branded information account, prior totransmitting to the selected consumer information elements to thenetwork device.
 61. The method of claim 60, wherein the client-sideapplication executes a communication protocol for communicating with adatabase management system that manages the data repository.
 62. Themethod of claim 60, wherein: the client-side application receives theselected consumer information elements and auto-populates the selectedconsumer information elements into at least one input field of the webpage file; and the web page file is submitted to the vendor server forprocessing of the selected consumer information elements.
 63. A tangiblecomputer-readable medium having stored thereon computer-executableinstructions that, if executed by a computing device, cause thecomputing device to perform at least a portion of the method of claim62.
 64. The method of claim 50, wherein: the selected consumerinformation is used to complete a transaction; and the method furthercomprises: maintaining a transaction log indicating an originatingvendor credited with facilitating origination of the branded informationaccount and a transacting vendor credited with using the brandedinformation account to complete the transaction; and sharing revenuereceived in connection with the transaction with the originating vendorand the transacting vendor according to a revenue sharing model.
 65. Themethod of claim 64, wherein the revenue sharing model specifies that therevenue shared with the originating vendor or the transacting vendorcomprises a specified percentage of the revenue received in connectionwith the transaction.
 66. The method of claim 50, wherein the consumerinformation elements are stored in the data repository in a tagged dataformat.
 67. A method for managing consumer information, comprising:storing an information account in a central data repository accessiblevia the distributed network, the information account comprising aplurality of consumer information elements associated with a consumerand identifying a sponsor of the information account; normalizing someof the consumer information elements into one or more discrete dataaggregates; receiving, over the distributed network, a request from aclient device for one or more selected consumer information elements,the client device interacting with a web page file hosted by a vendorserver, the vendor server being a member of an exchange comprising alogical grouping of servers authorized to interact with one or moreinformation accounts, the request including consumer authenticationinformation and an exchange identifier and being made by the clientdevice responsive to an input command supplied by the consumer; and inresponse to the request, authenticating the client device using theauthentication information by: authenticating the exchange identifier toensure that the exchange is authorized to interact with the informationaccount; retrieving the selected consumer information elements from theinformation account, where retrieving the selected consumer informationelements includes applying a transformation mechanism to data in theinformation account so that only the requested consumer informationelements are extracted from the information account; and transmittingthe selected consumer information elements, over the distributednetwork, to the client device.
 68. A tangible computer-readable mediumhaving stored thereon computer-executable instructions that, if executedby a computing device, cause the computing device to perform at least aportion of the method of claim
 67. 69. The method of claim 67, whereininformation account is valid only within the exchange and not within anyother exchanges.
 70. The method of claim 67, wherein the informationaccount is valid within the exchange and within at least one otherexchange.
 71. The method of claim 67, wherein the network deviceauto-populates the selected consumer information elements into web-pagefile displayed to the consumer.
 72. The method of claim 67, wherein: theselected consumer information elements are used to complete atransaction; the central data repository maintains a transaction logindicating an originating vendor credited with facilitating creation ofthe information account and a transacting vendor credited with using theinformation account to complete the transaction; and the method furthercomprises sharing revenue received in connection with the transactionwith the originating vendor and the transacting vendor according to arevenue sharing model.
 73. A tangible computer-readable medium havingstored thereon computer-executable instructions that, if executed by acomputing device, cause the computing device to perform at least aportion of the method of claim
 72. 74. The method of claim 72, whereinthe revenue sharing model specifies that the revenue shared with theoriginating vendor or the transacting vendor comprises a specifiedpercentage of the revenue received in connection with the transaction.75. The method of claim 67, wherein the consumer information elementsare stored in the central data repository in a tagged data format.
 76. Amethod for managing consumer information, comprising: storing aninformation account in a central data repository accessible via adistributed network, the information account having been created via awebsite associated with an originating vendor; encrypting a plurality ofconsumer information elements and storing the plurality of consumerinformation elements in the information account; receiving, over thedistributed network, a request from a network device for one or moreselected consumer information elements, the request including consumerauthentication information and being made by the network deviceresponsive to an input command; in response to the request,authenticating the consumer based on the authentication information,retrieving the selected consumer information elements from theinformation account, and transmitting the selected consumer informationelements, over the distributed network, to the network device; whereinthe network device auto-populates the consumer information elements intoa web page file displayed to the consumer for optional editing by theconsumer and for submission to a business process, associated with avendor, for completion of a transaction; and in response to receiving,over the distributed electronic network, an acknowledgment from thenetwork device that the transaction has been completed, sharing anyrevenue received in connection with the transaction with the originatingvendor and the transacting vendor according to a revenue sharing model.77. A tangible computer-readable medium having stored thereoncomputer-executable instructions that, if executed by a computingdevice, cause the computing device to perform at least a portion of themethod of claim
 76. 78. The method of claim 76, wherein the revenuesharing model specifies that the revenue shared with the originatingvendor or the transacting vendor comprises a specified percentage of therevenue received in connection with the transaction.
 79. The method ofclaim 76, wherein: the network device comprises a vendor serverinteracting with a client device, the vendor server executing aserver-side application for interacting with a database managementsystem that manages the central data repository; the vendor server is amember of an exchange comprising a logical grouping of serversauthorized to interact with one or more information accounts; therequest further includes an exchange identifier for identifying theexchange; and in response to the request, the exchange identifier isauthenticated to ensure that the exchange is authorized to interact withthe information account, prior to transmitting to the selected consumerinformation elements to the network device.
 80. A tangiblecomputer-readable medium having stored thereon computer-executableinstructions that, if executed by a computing device, cause thecomputing device to perform at least a portion of the method of claim79.
 81. The method of claim 79, wherein the information account is validonly within the exchange and not within any other exchanges.
 82. Themethod of claim 79, wherein the information account is valid within theexchange and within at least one other exchange.
 83. The method of claim76, wherein: the network device comprises a client device executing abrowser for interacting with the web page file hosted by a vendorserver; the web page file includes an instruction that causes thebrowser to request transmission of a temporary client-side applicationconfigured to manage the request/response process for the client device;the vendor server is a member of an exchange comprising a logicalgrouping of servers authorized to interact with one or more differentlybranded information accounts; the request from the network devicefurther includes an exchange identifier for identifying the exchange;and in response to the request, the exchange identifier is authenticatedto ensure that the exchange is authorized to interact with theinformation account, prior to transmitting to the selected consumerinformation elements to the network device.
 84. The method of claim 76,wherein the consumer information elements are stored in the central datarepository in a tagged data format.
 85. A system for managing consumerinformation, comprising: a data repository for storing a plurality ofinformation accounts accessible via a distributed network, theinformation accounts each comprising a plurality of consumer informationelements associated with a consumer; a host server in communication withthe distributed network and hosting a database management system forinteracting with the data repository; at least one exchange comprising alogical grouping of vendor servers in communication with the distributednetwork and authorized to interact with one or more of the informationaccounts; a client device in communication with the distributed networkand executing a browser for interacting with a web page file associatedwith a vendor server; wherein the client device requests from the hostserver one or more selected consumer information elements from theinformation account of the consumer, the request including consumerauthentication information and an exchange identifier identifying theexchange of which the vendor server is a member; and wherein in responseto the request from the client device, the host server authenticates theconsumer based on the authentication information, authenticates theexchange identifier to ensure that the exchange is authorized tointeract with the information account of the consumer, retrieves theselected consumer information elements from the information account ofthe consumer, and transmits the selected consumer information elements,over the distributed network, to the client device.
 86. The system ofclaim 85, wherein the web page file includes an instruction that causesthe browser to request transmission of a temporary client-sideapplication configured to manage the request/response process for theclient device.
 87. The system of claim 86, wherein the client-sideapplication executes a communication protocol for communicating with thedatabase management system that interacts with the data repository. 88.The system of claim 86, wherein: the selected consumer informationelements are auto-populated into input fields of a web page displayed bythe client device, the selected consumer information elements being usedby the vendor server to complete a transaction; and in response to thereceiving an acknowledgment that the transaction is complete, the hostserver stores in a transaction log transaction information associatingthe transaction with an originating vendor credited with facilitatingcreation of the information account and a transacting vendor creditedwith using the information account to complete the transaction, so thatany revenue received in connection with the transaction may be sharedwith the originating vendor and the transacting vendor according to arevenue sharing model.
 89. The system of claim 88, wherein the revenuesharing model specifies that the revenue shared with the originatingvendor or the transacting vendor comprises a specified percentage of therevenue received in connection with the transaction.
 90. The system ofclaim 85, wherein the consumer information elements are stored in thedata repository in a tagged data format.